Reviewed at ec4f456c.

Right scope for the fix. The trio of changes composes coherently: (1) target the explicit entry as the root HTML source, (2) skip compositions/ discovery so sibling entries aren't linted, (3) skip lintMultipleRootCompositions entirely since "multiple roots" is not a real problem when the caller explicitly named which root to use.

Traced the pieces that keep working correctly under the entry-scope path:

• lintMissingOrEmptySubComposition(projectDir, rootHtml) at project.ts:249 walks data-composition-src refs from the root HTML — and those refs are always root-relative (per the comment mirroring assertSubCompositionsUsable), so scoping the root to standalone.html still resolves its sub-compositions correctly against projectDir. No regression.
• collectExternalStyles(projectDir, rootHtml, rootCompSrcPath) — the newly-added rootCompSrcPath correctly threads the entry's rel path into collectLocalStylesheets, matching how nested sub-compositions already pass compSrcPath at project.ts:233. Stylesheet resolution stays consistent between the two.
• The explicitEntry = args.composition && args.composition !== "." ? entryFile : undefined guard in render.ts is correctly derived — entryFile is set from resolveCompositionEntryArg(args.composition, ...) (statSync-validated) at line 396, so by the time we reach the lint gate the path is known-good.
• Callers lint.ts:47, preview.ts:215, publish.ts:44 all still call lintProject(dir) positionally — the new entryFile? optional parameter is a pure additive extension, so those keep the old behavior.

Nits

• 🟡 rootFile = relative(resolve(projectDir), indexPath).replace(/\\/g, "/") || "index.html" at project.ts:186 — if the caller passes an entry file outside projectDir, relative() produces "../other/entry.html", which flows into results.push({ file: rootFile }) and every downstream lint reporter as a path with parent traversal. No security issue (the file is still read from indexPath, not the rel path), but the display + asset resolution would misbehave. The caller in render.ts won't produce that shape today, but the function is now exported with a wider contract than that. A if (!indexPath.startsWith(resolve(projectDir))) throw new Error(...) guard would fail fast for future callers.

• 🟡 Test covers the passing case (clean project, entry with 0 findings). Would be tighter to also assert that when the entry file itself contains real findings (e.g. a broken asset reference in standalone.html), those DO surface — proves the explicit-entry path is reporting entries, not just silently skipping the whole lint. One extra test case.

LGTM. Base of the stack — moving on to #2307 which builds on this.

— Review by Rames D Jusso

R2 reviewed at 89307271, delta from R1 head ec4f456c.

Both R1 nits cleanly addressed:

• Outside-project guard — isWithinProjectRoot(projectDir, indexPath) gate at packages/lint/src/project.ts:188 reuses the same helper already used by resolveLocalAssetCandidates (line 142), so behavior is symmetric with the rest of the module. resolve(entryFile) without a base is safe here because the guard's relative(projectRoot, candidate) + !startsWith("..") && !isAbsolute(relativePath) catches both absolute-outside and CWD-relative escapes.
• Non-clean explicit-entry regression — new it("reports findings from an explicit render composition entry", ...) asserts totalErrors > 0 and matches media_missing_id on the explicit entry. Companion it("rejects an explicit render composition entry outside the project", ...) locks the guard message shape.

LGTM from my side.

— Review by Rames D Jusso

Approving on Rames-D's go (R2 delta clean, nit round addressed) + Magi's CI-green confirmation. Verified at final head 89307271: CI green, no changes-requested, mergeable.